\label{defenses}
\section{CSRF Defenses}
As discussed in section \ref{CSRFattack} a CSRF attack can be countered by either enabling the server to
identify the origin of the request or use a secret session token with the user, to make not feasible for
the attacker to send a forged request.  All the defense mechanism discussed in the this section employ one
of these two methods, some of them with the slight variation that the web browser might be responsible to block
request, or content from unauthorized sources, as instructed by the server.

\subsection{Secret Validation Token}
A common and very secure method employed to counter CSRF attacks is to include a secret token, that is session 
depended in every form that needs to securely submitted to the server.  This token should be hard for the attacker
to guess and should vary between different users and sessions.  The secret validation token can be generated from 
a Session Identifier which is unique for each user, and hard to guess. A disadvantage of this technique is that if 
the session identifier leaks to a website, then anyone that visits that website can see that session identifier, and 
impersonate its owner, until the session cookie expires. Another method is to use a random generated nonce,
store it in a cookie associated with the user's Session Identifier and check it on every request. The problem here is 
that the server needs to maintain a large state table. A way to bind the secret token with a user's id, that does not
require a large state table, is to use the HMAC of the token and the user's session Identifier (see Ruby on Rails 
\cite{website:ruby}).

\subsection{Referer Header}
Most web browsers have the ability to sent a Referer request header to the server, identifying the origin of the request.
The server can then determine if the source is a legitimate URL, possibly from the website's domain, or a fraud.  Although
this solution to the CSRF thread problem seems appealing, the Referer header is optional for the browser, since due to the
nature of the HTTP protocol, the header will leak sensitive information, such as the content of the query, which rises
serious privacy concerns.  For this reason, the Referer header is often suppressed by web browsers.  In the absence of the
header, the server can either allows access, which deems the defense ineffective or deny access, in which scenario it is
possible that a legitimate user will be denies access to the server's content.  According to \cite{Barth:2008:RDC:1455770.1455782},
the number of users that would be denied access under this scenario is very high.  

\subsection{Custom XMLHtmlHeader}
websites that use AJAX to implement their interface need to make use of the XMLHtmlHeader.  An attractive property of
using the custom XMLHtmlHeader is that web browsers do not allow websites to send such headers to URLs outside of their
domain.  XMLHtmlHeaders can only be sent from a website to itself, thus the attackers effort to send such a header from
his website will be blocked by the victim's browser.  In order for the defense to be effective, site administrators must
take care to deny all state modifying requests that are made without an XMLHtmlHeader.

\subsection{Origin Header}
The Origin header, as proposed in \cite{Barth:2008:RDC:1455770.1455782}, works in similar fashion to the Referer header with
main difference that it leaks no information about the query that is being made.  The information included are only the required
ones from the server to identify if the origin of the request is a legitimate source.  If the browser cannot determine the
source of the request, then the origin value is set to null, and it's up to the server to decide what action to take.  
Moreover, the Origin header  is sent only for POST requests, to avoid leaking any sensitive information over the network.
Another sublime difference between the Origin and Referer header is that, since the privacy issue has been addressed in
the first, supporting browsers will always provide the Origin header, thus the attacker cannot trick the server to believe
that the browser does not provide the header, where such a scenario is possible when using the Referer header.  The Origin
header is also proposed as a standard by W3C \cite{website:w3c-cors}. 

\subsection{X-Frame Header}
Originally implemented in IE8, it has now been adopted by all major web browsers.  If the header is provided, it can
instruct the web browser not to display the content of the website in a frame.  The header can hold two distinct value,
DENY and SAMEORIGIN.  The first one force the browser no to display the content of the web page in any frame, while the
second allows frames to display its content,  if the the page using the frames, is the someone that delivered the content
in the first place.  The browser however needs to support this function, so it cannot be regarded as the first line of
defense by website administrators.

\subsection{Content-Security-Policy Header}
Content-Security-Policy (CSP) header has been recently introduced in order to address the various content injection vulnerabilities
present in most websites.  CSP header issues directives to the web browser on how to handle certain content, when loading
a web page.  For instance a server could instruct the web browser not to load scripts, images or other elements from
specific sources and only. Consider the following example:
\begin{lstlisting}
Content-Security-Policy:/
img-src 'self'
\end{lstlisting}
This directive instructs the web browser to only load images from the server's own origin.  The CSP header directive 
have to bee enforced by the browser, however if the browser does not support them, they will be ignored, making this 
kind of defense ineffective.  CSP header should provide an additional layer of defense, and website administrators
should provide other CSRF countermeasures as well.
